1. Field of the Invention
The present invention generally relates to flow charts for problem resolution, and in particular to techniques for the development of such flow charts.
2. Background Description
The established procedure for diagnosing a problem in a faulty system is often embodied in a flowchart or decision tree. The system can be a piece of hardware, a piece of software, or a combination of hardware and software components. The diagnostic procedure may be executed by support personnel at a call center, by a voice response unit, by a web application when the system user seeks self-help, or it may even be executed automatically by the system itself in self-healing environments.
A flowchart is a very natural way of representing the knowledge needed to diagnose problems. If the flowchart is comprehensive, it is usually easy for a human, even a non-expert, to follow the flowchart and diagnose the problem. At each node the human (or machine) can elicit the necessary information and decide which branch to follow, until a leaf is reached at which no more information is needed and the diagnosis is obtained. Flowcharts are a very good way of documenting the knowledge developed over time by people in resolving complex problems using their experience and expertise.
However, flowcharts suffer from a number of difficulties that restrict their utility for many applications. Firstly, they are quite difficult to author manually. It is quite expensive to obtain the necessary knowledge from human authors, because a large number of possible branches need to be considered to create a comprehensive flowchart. Even if a good initial flowchart can be manually built, maintaining the flowchart is an endless source of further difficulty. For example, every time a new type of fault is discovered, it needs to be added to the flowchart. A human being will at best typically add a new fault so that it does not take too long to diagnose and does not cause too much modification of the underlying flowchart structure. This can quickly result in the flowchart becoming unmanageably complex and incomprehensible.
A second major problem with manually authored flowcharts is that they are almost always sub-optimal. An optimal flowchart is one that minimizes the average cost of diagnosis, e.g., the average number of questions: common problems should be diagnosed more quickly by asking about them first, before asking about less common problems. To maintain optimality, a diagnostic flowchart must necessarily modify itself in response to changes in the frequency with which symptoms and problems occur. Manually authored flowcharts tend to become increasingly sub-optimal over time because of the difficulty of maintaining them. This can result in unnecessarily expensive diagnostic procedures—a particularly annoying example of this is the asking of unnecessary questions when consulting customer help.
It is of course possible to construct a flowchart using traditional decision-tree learning from training data. However, training data can be difficult to obtain (a working diagnostic system must already be in place before any training data can be collected). Furthermore, this approach fails to take advantage of the knowledge of human experts. People often have a very good understanding of what information should be elicited to perform the diagnosis, but they are usually unable to arrange the questions in the optimal order, given the frequency of the problems and symptoms and the complexity of considering all possible diagnostic paths.
For example, in recent times telephone help centers have become a widely used means for resolving customer problems. In a typical help center, a customer will be referred to someone trained to listen to the customer's problem and ask questions in a dialogue that leads to a solution for the customer. If the initial trained person is not able to resolve the problem, the customer may be referred to a second tier of experts with greater training and experience.
In order to improve their performance, help centers have developed flow charts showing questions that should be asked, with branching points to further questions based on the answers received, eventually leading to resolution of the customer's problem. These flowcharts are developed and modified based on experience accumulated over time by operation of the help center.
However, as more experience is accumulated and small changes are made in increments to adapt to the new experience, the flow charts tend to grow and develop without the benefit of a fresh assessment of the most efficient sequence for asking the questions. The flow charts become increasingly difficult to maintain.
The classical resolution of this problem was the evolution of Case Based Reasoning, which was explored heavily in the 1990s. Case Based Reasoning systems collected expertise in a library of past cases, where each case contained a description of the problem and the solution. To solve a current problem, the system retrieves past cases having similar problems and these past cases are used to suggest a solution, which is then tested and revised, as necessary, and added to the library.
Case Based Reasoning systems tended to succeed in fields which lacked a strong “domain theory” i.e. in fields where the connection between symptoms and causes was weakly understood. However, this is not typically the case in many helpdesk scenarios.